在任何前端允許輸入的地方，都需要做正規化、白名單，
再不然也要檢查驗證內容、資料消毒或是黑名單，
然後也要加上try-catch exception 處理，
不然就會成為前端注入的點。

https://www.facebook.com/memesengineering/photos/a.2055435371144048/3107609955926579

這個攻擊情境有點像 XD

我在網咖 有個國小的屁孩說要把我的臉壓在鍵盤上
笑死我了哈哈哈哈哈哈哈哈哈哈哈哈
他以為他是jhkskjighiugihlklkeihlskir
就可來源：https://www.ptt.cc/bbs/joke/M.1398328812.A.2E8.html

輸入的內容：jhkskjighiugihlklkeihlskir
如果允許的字串內容沒有做任何處理，可能就直接顯示Debug頁面了 XD
或是系統預計在這串指令做出【高度的運算】，則【多個請求】【同時】可能會耗費大量資源，造成服務中斷(DDos)。
如果發現在金流單位、線上支付或是線上服務可能就會造成高度的損失。

最有趣的地方在於搜尋列：
像說通常我們輸入的內容，會重覆的出現在下一個頁面：

然後我們可以試著在Youtube 分享時，在搜尋列嵌入的語法：

直接點以下連結，就能在 Demo 網站看到指定的嵌入內容了。
https://demo.testfire.net/search.jsp?query=%3Ciframe+width%3D%22560%22+height%3D%22315%22+src%3D%22https%3A%2F%2Fwww.youtube.com%2Fembed%2Fyzr-xC_7cHU%22+frameborder%3D%220%22+allow%3D%22accelerometer%3B+autoplay%3B+clipboard-write%3B+encrypted-media%3B+gyroscope%3B+picture-in-picture%22+allowfullscreen%3E%3C%2Fiframe%3E

以上的情境就是反射型跨站腳本(XSS)的應用。

但比較嚴重的點通常是相關金額的情境：
像說後端未重計金額，造成前端改金額為負數，照單全收的狀況：


或是點數前端自行輸入，後端未驗證直接折扣：

來源新聞：https://www.setn.com/News.aspx?NewsID=95290

大guy4醬紙的概念！